All Posts By

María Teresa Nieto, Blockchain Technological Specialist at Telefónica

Telefónica TrustID, its decentralized Identity solution, moves to Hyperledger Labs

By Blog, Hyperledger Labs

Earlier this year, we wrote a post for the Hyperledger blog about how we were working in Telefónica to face the challenges of managing identities in a new and actually decentralized way. Based on the interest raised by this work, we proposed TrustID as a new project under the umbrella of Hyperledger Labs. TrustID was accepted and has moved to Hyperledger Labs so, from now on, the open source community will contribute to the evolution of the solution initially developed by Telefónica. The aim is to develop a new standard to simplify identity management in blockchain networks regardless of the underlying technology of the networks.

Over the past few years, we have witnessed the development and creation of digital identity solutions based on blockchain technology. However, most of these solutions are in silos, not interoperable, and dependent on the underlying technology.

The same credentials used to access your owned Bitcoins and manage your tokens in Ethereum should let you update the state of a Hyperledger Fabric asset. This is the rationale behind TrustID. In the end, the goal that we have set for TrustID is to create a cross-platform mechanism to manage one unique identity to have access to any blockchain. It doesn’t matter if the network you are operating on is based on Hyperledger technologies (Fabric, Besu, Indy, etc.) or other common blockchain technologies.

In Hyperledger Fabric, identities are centralized by the Certificate Authorities (CAs) that have issued those identities. Initially, TrustID implements identity management in Hyperledger Fabric as a decentralized alternative to CAs by using the DID standard specified by the W3C. However, we expect to make it compatible with more Hyperledger platforms like Besu or Indy and even other blockchain technologies other than Hyperledger ones.

Going into a deeper level, TrustID is made up of two components: (1) a library (SDK) that implements the management of a single identity and (2) a chaincode to implement this logic in the blockchain in a decentralized way. That single identity will be interoperable with other identities on different blockchain platforms wallets.

At Telefónica, we started TrustID as a module to make it easier to enable identity management for our product TrustOS. Beyond our product need, TrustID solved a common issue for many blockchain projects. We realized it could be more than a module and instead be a standalone project itself. As we shared this vision with other members in the community, we confirmed the interest in the TrustID approach for managing identities, so we decided the best way to make it really awesome was to open source it. Hyperledger Labs became the best option. In the roadmap, we are envisioning a compatibility of TrustID with the proposal of the Sidetree protocol and Verified Credentials from the DIF (Decentralized Identity Foundation), and its integration with other projects of the ecosystem such as Hyperledger Cactus, Indy and Besu.

We expect TrustID to grow thanks to its inclusion as an Hyperledger Lab. Last but not least, we’d appreciate any feedback and contributions from the Hyperledger community. We hope and  believe that TrustID is the starting point to allowing a level of interoperability between blockchain platforms for identity management. And remember, TrustID is looking for your contribution…We want you!

Fair Fashion: Promoting visibility and accountability in Brazil’s fashion supply chain

By Blog, Hyperledger Fabric

The Brazilian textile industry represents 10% of the nation’s industrial GDP, and it is also the second-largest employer in the country. Despite its importance, fashion is ranked second as the industry with most cases of forced labor or conditions similar to slavery.

As an effort to fight this problem, in recent years, brands and manufacturers in the textile industry have been auditing production sites. Because of the lack of integration between the actors of this production chain, auditings is still very inefficient, as it involves high costs and offers a vast scope of error. 

There are three main problems in the current audit model.

Because workers and auditors have a strictly professional, non-anonymous, and punctual relationship, there is no way to guarantee the veracity of the worker’s account. Moreover, in most cases, only a few workers are interviewed by the auditor, which makes the picture incomplete since it does not reflect the overarching reality of the production process.

Besides the possibility of human error and fraud, the current model has low auditing frequency (once a year), depends on third party institutions, and is very expensive. This scenario translates into inefficiency and generates doubts for the stakeholders since the benefits become unclear.

The third and most critical problem with this type of auditing is the lack of interface between the market and society. Since the whole process, from production to consumption, is not available and transparent for end consumers, key actors do not have adequate information to demand better conditions for workers or to make better consumption choices.

In addition, the fashion industry involves many intermediaries: seamstresses, workshops, factories, suppliers, brands. This amount of people makes it difficult to monitor all business productivity in a clear, integrated, and efficient manner.

Addressing this situation means taking on a number of challenges: How to connect actors in the supply chain, bringing business efficiency, predictability of delivery, and inventory? How to offer visibility to the production processes, and therefore give voice to the last mile of the chain? How to empower seamstresses and improve their working conditions?

To solve these problems and reverse this scenario, Blockforce – a Brazilian blockchain researcher and builder and general member of Hyperledger –  in partnership with C&A Foundation, Instituto E and COPPEAD-UFRJ, developed a blockchain-based solution called Fair Fashion. Designed using the Hyperledger Fabric framework, this solution promotes visibility and accountability in the fashion supply chain, with the goal of improving working conditions and the efficiency of processes in the production chain. 

This is done through the publication of indexes that explain correlations between demographics, working conditions, and stability in the supply chain based on traceability of order matching with a monthly census with workers at the end of the production chain.

The Fair Fashion solution works on three fronts:

Firstly, Fair Fashion offers workers an app to report their work conditions. By answering a monthly questionnaire, the respective workers involved anonymously provide an update on the working conditions behind all orders placed during the month. 

The second tool is an app for the actors on the business side to trace orders status and conditions. The orders placed by brands are captured by suppliers and then by factories, providing visibility to all production processes as well as the accurate and transparent order status for the entire chain.

Finally, a Dashboard that integrates the data obtained by the two sources of Fair Fashion’s apps provides an overview of all available data. On the Dashboard, each stakeholder – brands, suppliers, or workshops – has its customized visualization. 

Chained and dependent, the solution consists of two interfaces, the business interface and the social responsibility interface. Together they offer the cross view of data necessary to establish the interdependence between flows, and therefore accuracy in verifying the exposed indexes.

The business interface integrates the flow between brands, suppliers, and workshops. It allows the organization to monitor the order status – the number of products produced and delivered, current order status, and its immutable history. It may check, in an organized manner, all documentation of the establishment, including whether it is up to date or pending, and, finally, monitor the current situation of employees.

On the other hand, the social responsibility interface is a reflection of the survey answered by workers through the app. It provides the workshop’s evaluation according to the workers’ perspective, considering the following segments: physical space, health, safety, labor relations, and working conditions.

All information in both interfaces can be viewed on the Hyperledger Fabric-powered blockchain.

The Fair Fashion solution provides benefits for all stakeholders in the chain and, ultimately, for the sector in general since it is based on efficiency and social impact. By collecting data with higher frequency, greater accuracy, and less cost, brands have visibility throughout the chain, enabling preventive actions and helping to predict deliverability and storage. Workshops and suppliers monitor their productivity and social indicators and can improve their dialogue with brands and society. Finally, by answering an anonymous and confidential survey about working conditions, workers can report their situations, guarantee job stability, and participate in a consolidated network that gives a voice to their needs and realities, which are not always assisted.

Fair Fashion is a project sector initiative along with C&A Foundation/ Laudes Foundation, E institute and COPPEAD-UFRJ.  It is released in its first version. We’re facing the homologation phase for scale implementation. We are advancing tests on brands and actors that aim for this type of innovation in their chains. 

Let’s change the fashion industry together. Contact us to find out more details about the solution and how to be part of it here: https://blockforce.in/

Cover photo by Kris Atomic on Unsplash

Community Spotlight: Meet Saptarshi Choudhury, Hyperledger Public Sector Special Interest Group Co-Chair

By Blog, Community Spotlight, Special Interest Group

Welcome to our Community Spotlight series, which highlights the work of those taking on leadership roles in our special interest and working groups. Meet Saptarshi Choudhury, co-chair of the Public Sector Special Interest Group and Director of Emerging Technologies for Paramount Software Solutions.

Tell us about yourself. Describe your current role, your current business and background, and your involvement in the Hyperledger Public Sector SIG.

I am the Director of Emerging Technologies for Paramount Software Solutions. Since July 2018, I’ve primarily worked on digital transformation in enterprises through blockchain. Prior to that, I worked for AMK Solutions exploring the values of human dynamics and correlation with digital adoption. I started my engagement with the public sector in December 2012 as an electrical engineer for the infrastructure unit of HSCL. I hold a Bachelors and Masters in electrical engineering and have had the opportunity to glimpse the diversity of the world from the lens of different challenging roles. Last year in February, the Hyperledger Public Sector Special Interest Group (PS SIG) intrigued me as it drew attention from people all over the world with diverse backgrounds in technical, business, political or socio-economic frontiers. I have been regularly attending the biweekly meetings for the last one and a half years and am presently hosting the meeting as a co-chair with Dr. Hanna Norberg.

Where do you hope to see Hyperledger and/or blockchain in five years? 

Hyperledger is expanding the width and depth of its efforts to promote decentralization for trust and transparency through its evergreen projects. Distributed ledger technologies like Hyperledger Fabric and Hyperledger Sawtooth are gaining global attention as platforms for private and permissioned ledgers for enterprise applications whereas Hyperledger Indy is revolutionizing how we perceive the fundamental concept of Digital ID. This year Hyperledger Besu was featured in the Coindesk 50. There are other exciting projects like Iroha and Burrow that are on track to help solve critical challenges of the world through blockchain. My hope is that we will be able to make progress on different aspects with tools like Hyperledger Cactus on interoperability, Hyperledger Avalon on trusted off-chain transactions and Hyperledger Caliper on performance benchmarking. In addition, thanks to the Hyperledger Ursa library, we will be able to avoid duplicating cryptographic modules for different projects. 

What do you see as the biggest barrier to widespread blockchain adoption?

My take is that the biggest barriers are lack of clarity in policies and regulations covering the different aspects of blockchain and the need for standardization and interoperability among the evolving solutions.

What are the biggest opportunities ahead for blockchain developers?

The Hyperledger projects are based on software languages that are popular among programmers, and so they can get started without specialized training. The underlying coding background could be JavaScript, Python, Go or even Java. Even if someone has limited skill in coding, they don’t need to shy away from working with the community as the starting point could be adding value to the documentation team. They can also review and contribute to the projects in Github.

What is the Public Sector SIG working on currently? Any new developments to share? 

The Public Sector SIG is presently hosting biweekly presentations by interested volunteers from different parts of the world. We proactively monitor all the governmental policies and initiatives associated with blockchain. In addition, we are creating a database of all the blockchain initiatives in the public sector globally. Recently, there has been a surge of interest among the members to address the Covid-19 pandemic. We are also seeing interest in the Central Bank Digital Currency (CBDC).

What’s the most important milestone for the Public Sector SIG to reach in 2020? 

The unending pandemic of Covid-19 has tilted the focus on healthcare. However, there are people who also want to explore and understand the regulatory frameworks and progressive stance for blockchain in different countries. We as a community collectively intend to foster collaboration among public agencies, private organizations and nonprofits with the aim of cutting away barriers to sharing specific blockchain work across borders to minimize siloed efforts and parallel initiatives.

Why should someone participate in the group? Why is it important for Hyperledger to encourage collaboration around adopting blockchain technologies for public sector use cases? 

From an individual point of view, open source meetings are a hotbed for nurturing leadership skills and working in a collaborative environment. From the standpoint of Hyperledger, active community participation means solutions are designed and developed based on shared values and joint philosophy. The Public Sector SIG emphasizes wider adoption of blockchain technologies that add value to all irrespective of who they are or what their worldview entails. 

What are a few ways people can participate in and contribute to the Public Sector SIG? (i.e., What type of support does the group need?)

People can join the Public Sector SIG meetings that occur via Zoom every other Friday at 10am ET. They can also subscribe to the mailing list to stay updated about the latest progress in the community and contribute to the Hyperledger Wiki. To get involved, it’s best to create a Linux Foundation ID. I would also recommend going through the short clip on “How to get involved in the Public Sector SIG.”

Happy Pride Month!

By Blog, Working Group

Edit, June 1: In just the few days that elapsed between when this was penned and when it was posted so much has happened.

Today in discussing everything that is transpiring, someone pointed out that the roots of Pride Month are not just in the historic riot at Stonewall, but also riots at Cooper Do-nuts, Compton’s Cafeteria, and others.

As we think about what we do to build a diverse, civil, and inclusive community, we look for ways to show that everyone is welcome here and that their lives matter, that black lives matter.

______________________________________

Happy Pride Month from the Hyperledger open source community! We are proud to have an inclusive community here at Hyperledger. This year has some new challenges for all of us. While the pandemic impacts each of us differently, many of us involved in Hyperledger are fortunate to have jobs that we can do virtually. In fact, one of the reasons it is natural to be inclusive in open source is that it just takes an internet connection to get involved. Of course, it takes an active effort to be a contributor and an active effort from the community to make sure that everyone feels included.

We have a couple new initiatives to announce in Pride Month. First off, we are starting a new guest speaker series. Hyperledger is supported by large and small companies alike, and we are inviting leaders from these companies to come and talk about what Diversity, Civility, and Inclusion mean within their companies and how participating in open source helps. Our first speaker is Jim Gordon from Intel on June 10th: https://wiki.hyperledger.org/x/kw7cAQ

We were also looking forward to joining  our member companies at Pride Month events. The plan was to show our support at festivals and other activities and encourage their participation in this open source project. It is perhaps bittersweet that we were able to run Hyperledger Global Forum replete with our “All Are Welcome Here” message, but that might have been the last in-person event for many of us this year. As we looked towards Pride Month events, our nascent on-site plans have had to be curtailed. Fortunately, we are discovering that more and more events are finding a way to continue through virtual means. And as a do-ocracy YOU are welcome to help us be present and connect at those events.

Out and Equal is hosting a couple of virtual events including a June 1st kickoff for pride month and a June 15th virtual brunch: https://outandequal.org/virtual-offerings/

You are welcome to show up and represent the Hyperledger community at these events. 

More broadly, there’s a host of LGBTQ+ Tech organizations you can check for other events: https://www.pride.com/technology/2018/5/03/7-lgbt-tech-groups-you-should-know-about

Lesbians Who Tech, for example, is hosting what they are billing as, “… the largest LGBTQ tech gathering in history.” https://lesbianswhotech.org/virtualpridesummit/

If you make it to an event, let the rest of the community know by dropping in chat (https://chat.hyperledger.org/channel/dci-wg) or sending a note to the mail list (https://lists.hyperledger.org/g/dci-wg/).

Regardless of how you celebrate this month, have a healthy and proud month!

How digital identity empowers consumers and producers in a circular supply chain

By Blog, Hyperledger Fabric

Most of us can relate to wanting to know where our food comes from – if it is safe to eat, ethically sourced, and whether that commodity harms the environment or is produced in a sustainable way. The topics of food safety, recall, waste management and ethical sourcing are justifiably getting a lot of attention. Consumers are demanding a greater level of transparency and assurance.

What if we could empower consumers with more trusted information at their fingertips so they can directly reward and incentivize small scale suppliers around the world that are committed to following sustainable practices? Imagine a future where more people could fully participate in the growing value of the green economy. With a powerful combination of blockchain, digital identity, payments and Internet of Things (IoT) capabilities, we at Accenture believe this is possible and imperative.  

Leveraging these capabilities, we collaboratively developed a solution built on Hyperledger Fabric that generates a new kind of value for producers. We call this capability circular supply chain. 

Here’s how it works: Let’s imagine a coffee farmer, for example. Using an app on their phone, the producer creates a profile, entering basic details like their name, date of birth, and the name of their coffee farm. At their cooperative, their identity is validated, using multiple security protocols.

The farmer’s identifier is then recorded on the blockchain, which acts as an index with links to all applicable data—including things like their payment details so they can receive tips or add attestation that prove their farm’s inspection history and certification status (organic, etc.). This makes it easy to locate, access and share information without the farmer’s personal data being stored on the blockchain.  

The app on the farmer’s phone is multi-factored and authentication-secured; it allows the farmer to generate their own set of public and private keys seamlessly which the farmer can then use to sign data they send to others. 

The farmer is always in control of their data, determining which information is part of their public profile or what details will be linked to a particular product as it moves through the supply chain. They can also use the app as a management tool to keep track of product registrations, check their tip balance, renew certifications and prepare a harvest for shipment.  

When a shipment is ready and registered, a unique identifier is automatically generated, embedding information about the coffee, the farmer and their farm (like its organic certification), and then scanned, captured, and verified at the point of origin.

Sensors can then be added, and registered, to the product at the cooperative warehouse. These sensors can monitor temperature and humidity within the warehouse to ensure product quality. And if the conditions go out of the optimal range, an alert is generated, prompting the warehouse to take preventative actions before the product quality is compromised. 

These details, and each step the shipment takes along the journey, are scanned, added to the ledger and traceable as it moves across the supply chain—from farmers to processors to grocery store shelves and, finally, to end consumers. Now a simple scan not only tells consumers the story of their sustainably-sourced coffee and the farmers that grew it but empowers them to reward the farmer via a secure tip. 

The benefit is a circular supply chain that goes beyond where it started and creates a closer connection between consumers and small growers. Processors, distributors, wholesalers and retailers can trace product provenance, creating market differentiation for sustainability, food security and quality. The hope is that by aligning incentives through an immersive customer experience that fosters informed purchasing decisions, we can empower an inclusive economy that encourages the actions to mitigate environmental impact and benefit people. 

Accenture has created this capability, but it’s just a start. We invite organizations across industries and the globe to collaborate with us as we collectively build a more sustainable and inclusive world. 

Read our report on circular supply chain and learn how to collaborate with us. You may also be interested in joining the Hyperledger Identity WG or Supply Chain SIG to see how others in this space are approaching this digital transformation.

Cover image via Peakpx

Improving Disaster Relief Efforts with Blockchain Technology

By Blog, 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 3rd party verification: Needs can be verified by 3rd 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.
Sample Screen with Dummy Data

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)

Ramping up Roaming: Telekom Innovation Labs New Hyperledger Fabric-Based Solution to Automating the Growing Volume of Telco Wholesale Agreements

By Blog, Hyperledger Fabric

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.

Sawtooth PBFT, Part 2: Extensions and Changes

By Blog, Hyperledger Sawtooth

The upcoming release of Hyperledger Sawtooth 1.2 includes Sawtooth PBFT—a new, Cargill-sponsored, production-ready consensus algorithm. Sawtooth PBFT is much more than a basic implementation of the PBFT consensus algorithm that was originally defined in 1999. Sawtooth PBFT has all the core features of the original definition—it provides the same safety and liveness guarantees—but we have adapted the algorithm to take advantage of features unique to blockchains, and extended it to provide more flexibility and robust guarantees.

In two earlier blog posts, Making Dynamic Consensus More Dynamic and Introduction to Sawtooth PBFT, we introduced Sawtooth’s dynamic consensus interface and explained how the PBFT consensus algorithm works from a high level. In this post, I’ll describe the adaptations and enhancements that helped us bring a robust PBFT consensus algorithm to Hyperledger Sawtooth:

  • Sequence number simplications (no more watermarks)
  • An idle timeout to guarantee more liveness
  • Regular view changes for fairness
  • A consensus seal as proof of commit
  • No checkpoints for garbage collection
  • A catch-up procedure for slow and new nodes
  • Membership changes

Sequence Number == Block Number

In traditional PBFT, the primary node assigns a sequence number for each request when it broadcasts a pre-prepare message for the request. In Sawtooth PBFT, the “requests” are actually blocks that are created by a Sawtooth validator. Blocks in Sawtooth are ordered; we can take advantage of this ordering to simplify the sequence numbering in PBFT. Instead of assigning a sequence number for each block, the primary node will just use the block number as the sequence number.

This simplification makes the algorithm easier to understand. It also means that secondary nodes don’t need to check that the primary node picks reasonable sequence numbers. Originally, nodes would have to make sure that the sequence number was between a low and high watermark, in case the primary node picked a number that was so high that it exhausted all of the possible sequence numbers. Now that the sequence number is automatically determined by the block number, a secondary node only needs to check the pre-prepare message to make sure that the sequence number matches the block number of the block in the message. It’s as simple as that!

More Liveness with an Idle Timeout

One liveness problem that traditional PBFT does not solve is the “silent leader” problem. The leader is responsible for building and sharing blocks with the rest of the network to start a new round of consensus. Even if transactions are being submitted to the network, the leader could stay silent by never sharing a block with the network; this “silent leadership” would allow the leader to halt progress indefinitely.

To solve this problem, we implemented an idle timeout as a new way to trigger a view change. After a block is committed, each node starts its idle timer. The primary node must publish the next block and broadcast a pre-prepare message for the block before the timer expires. Otherwise, a secondary node will initiate a view change.

The idle timeout provides more robust liveness by ensuring that a faulty primary node can’t stall the network indefinitely. This timeout can lead to unnecessary view changes, though; if the network really is idle (no transactions are being submitted), then the primary node isn’t faulty when it doesn’t publish a block, since the Sawtooth validator does not publish a block when there are no transactions. The cost of these extra view changes is negligible, however; when the network is idle, a view change will not hinder the performance of the network.

Pseudo-Fairness with Regular View Changes

Determining if a leader is acting fairly is a very complex and challenging problem; there is still a lot of research being done to solve it.

To get us a step closer to fairness, we introduced a regular view change mechanism to Sawtooth PBFT. This mechanism is fairly simple: after every nth block is committed, the network will “force” a view change by incrementing its view by one. The number of blocks between forced view changes is called the forced view change interval, which is a configurable setting.

Regular view changes reduce unfairness by not allowing any node to control block publishing for too long; instead, every node gets a chance to be the leader for a period of time. While this doesn’t completely solve the fairness problem, it limits unfairness in a way similar to Tendermint and lottery-style consensus algorithms. This solution is also inexpensive: since the view change is “forced” (the view number is directly incremented) at a consistent point across the network, we don’t need the expensive view changing procedure.

Consensus Seal

The original PBFT algorithm does not define a reliable way to check if a block was committed validly (that is, when 2f + 1 nodes agreed to commit the block). The only way to check this would be to request each node’s commit messages and count them. The problem with this approach is that old messages might be unavailable if the messages were removed (garbage collected) or if a node is no longer part of the network.

To overcome this limitation, we implemented a consensus seal for each block that is committed. The consensus seal is a signed data structure that contains a block ID and 2f signed commit messages for that block ID. This seal proves that the network agreed to commit the block and that the block was committed validly.

The seal is stored on the blockchain itself, which means that the seal is immutable and can be checked at a later point. A seal can’t be inserted directly into the block that the seal is for, however, due to the way blocks are constructed by the Sawtooth validator. Instead, the seal is added to the next block that is committed to the blockchain; thus, each block contains the consensus seal for the previous block. This approach has a limitation—the most recently committed block can’t be validated using a consensus seal, since there isn’t a subsequent block yet. However, all previous blocks in the chain can be validated to ensure that they were committed validly, which is a useful guarantee.

Catching Up

In the real world, distributed networks face failures, segmentations, dropped messages, and many other hiccups. When these issues arise, nodes may fall behind, so they need a way to catch up to the rest of the network.

Sawtooth PBFT uses a special catch-up procedure that takes advantage of the consensus seal extension. The catch-up procedure is best illustrated by an example.

Let’s say the network as a whole has committed block 100, but a node has fallen behind and has only committed blocks up to block 90. When the slow node eventually gets block 91, it waits for a pre-prepare message from the primary node. Because the network has already moved past this block, though, the node never gets this old pre-prepare message. Instead, the slow node gets block 92, which contains a consensus seal for block 91. The node examines the seal from block 92 to make sure it’s valid, then commits block 91. Our node knows that it can skip the usual consensus procedure because the consensus seal in block 92 proves that the network agreed to commit block 91.

The node follows this procedure until it commits block 99. At this point, it needs to do something different. Because there is no block 101 yet, the node doesn’t have a seal for block 100. So the node broadcasts a request to the rest of the network for a consensus seal for block 100. If another node has already committed block 100, that node builds the seal and sends it directly to the node that requested it. When the node receives the seal, it will verify the seal and commit block 100. The node that fell behind is now up to date!

Who Needs Checkpoints?

As originally defined, PBFT uses a checkpoint procedure to perform garbage collection for each node’s log of consensus messages. In this procedure, the nodes exchange messages to come to consensus on the current version of state. When the nodes have agreed on the current state, they save these messages as proof of the agreement, then discard all previous consensus messages.

Sawtooth PBFT does not need this checkpoint procedure. Because each block contains a consensus seal that provides proof of the validity of the previous block, and each block is immutable and permanent by nature of a blockchain, every block contains a checkpoint that will be kept forever. This means that the nodes can clean up old log messages any time they wish, while the state can still be verified using the consensus seal.

Membership Changes

Another fact of the real world is that network membership can change. This happens for a variety of reasons: a node may need to be replaced or a new company might want to join a consortium’s network. The original PBFT algorithm does not define a procedure to change membership of a PBFT network, so we implemented our own.

In Sawtooth PBFT, membership in the network is determined by an on-chain Sawtooth setting, sawtooth.consensus.pbft.members, which is a list of the public keys of all nodes in the network. Since this list is on the blockchain itself, it’s shared and agreed on by the whole network, which makes changing membership easy.

An administrator can update the on-chain setting to add, remove, and reorder nodes by submitting the change as a transaction. Each time a block gets committed, all PBFT nodes check this setting to see if it changed because of a transaction in that block, then update their local state if necessary.

Like forced view changes, a membership change is done at a consistent point across the network: when a block is committed. This consistency makes the local view of membership on each node easy to update in an atomic way. This approach to membership also makes it easy to check the historical membership throughout the life of a Sawtooth blockchain managed by PBFT consensus.

Summary

Sawtooth PBFT has a lot to offer. It not only includes all the functionality you would expect from PBFT, but it adds features and optimizations for real-world use. We’ve developed new solutions to overcome limitations of traditional PBFT. Plus, we’ve been able to take advantage of the properties of a blockchain, such as immutability and ordering, to make the algorithm more efficient and robust.

Want to Learn More?

These features are all new to PBFT, and some of the implementations are unique among published consensus algorithms. If you’re interested in learning more about our PBFT extensions, read the regular view changes RFC, consensus seal RFC, and PBFT catch up RFC. Also, check out the Sawtooth PBFT documentation and source code on GitHub.

Do you have questions? Do you have comments or concerns about how the extensions work? Let us know in the #sawtooth-consensus-dev channel on Hyperledger Chat!

Stay tuned for more news and info about the upcoming Sawtooth PBFT 1.0 release.


About the Author

Logan Seeley is a Software Engineer at Bitwise IO. He has been a part of the Hyperledger Sawtooth community since May 2018,


Making Dynamic Consensus More Dynamic

By Blog, Hyperledger Sawtooth

In October 2017, the Hyperledger Sawtooth team started to implement a new consensus algorithm for Hyperledger Sawtooth. We wanted a voting-based algorithm with finality, which is very different from the Proof of Elapsed Time (PoET) consensus algorithm that has been closely associated with Hyperledger Sawtooth since its start. This project presented a number of challenges and opportunities.

The greatest challenge in implementing this new consensus algorithm with Sawtooth was in breaking apart an architecture that has been heavily influenced by a lottery-based consensus algorithm with forking. A lot of refactoring and architectural work went into making both voting-based and lottery-based algorithms work well with Sawtooth.

However, the opportunities that we discovered from this effort made overcoming these challenges more than worth it. We designed a new consensus API that simplifies the process of adding new consensus algorithms while continuing to support the existing PoET and Dev mode consensus algorithms. We completed the first prototype validator with consensus API support in July 2018. Since then, we have been able to implement two new voting-based consensus algorithms for the Hyperledger Sawtooth platform: Raft and PBFT.

We are pleased to announce that the Sawtooth 1.1 release supports the new consensus API. This release also includes consensus SDKs to make it easier to implement new consensus algorithms.

Consensus as a Process

The new consensus architecture moves consensus functionality to a separate process, called a consensus engine, and provides an API for each consensus engine to interact with the validator.

Moving the consensus functionality to a separate process allows consensus engines to be implemented in a variety of languages. Currently, SDKs are available for Python and Rust and have been used to create the consensus engines for PoET, PBFT, and Raft.

Multi-language support is important beyond providing a choice for implementing a new consensus engine. This support makes it much easier to reuse existing implementations of consensus algorithms. For example, the Sawtooth Raft consensus engine is built on the pingcap/raft-rs library. We were able to easily integrate this well-regarded Raft library, which is itself a port from the widely-used etcd Raft library.

As SDKs for additional languages are built on top of the consensus API, it will be possible to add more and more consensus algorithms into Hyperledger Sawtooth. For example, a consensus SDK for Go would bring existing implementations such as Hyperledger Labs’ MinBFT one step closer to being compatible with Sawtooth.

Driving the Blockchain with a Consensus Engine

The consensus API is centered around a new consensus engine abstraction that handles consensus-specific functionality. A consensus engine is a separate process that interacts with the validator through the consensus API using protobuf messages and ZMQ.

The role of a consensus engine is to advance the blockchain by creating new blocks and deciding which blocks should be committed. Specifically, a consensus engine must accomplish the following tasks:

  • Determine consensus-related messages to send to peers
  • Send commands to progress the blockchain
  • React to updates from the validator

The validator continues to handle the mechanics of validation, communication, and storage for blocks, batches, and transactions. The validator must perform these tasks:

  • Validate the integrity of blocks, batches, and transactions
  • Validate the signatures for blocks, batches, transactions, and messages
  • Gossip blocks, batches, and transactions
  • Handle the mechanics of block creation and storage
  • Manage the chain head directly

New Consensus API and SDKs

The validator exposes the API for consensus engines as a set of protobuf messages sent over a network interface. This API is split into two types of interactions:

  • Service: A pair of (request, response) messages that allow a consensus engine to send commands to the validator and receive information back. For example, a consensus engine can instruct the validator to commit a block or request an on-chain setting from a specific block. Services are synchronous and on-demand.
  • Updates: Information that the validator sends to a consensus engine, such as the arrival of a new block or receipt of a new consensus message from a peer. Updates are sent asynchronously as they occur.

Although you could use the API directly to implement a new consensus engine, the recommended interface is a consensus SDK. The SDK provides several useful classes that make it easier to implement a consensus engine. Sawtooth currently provides consensus SDKs for Python and Rust. We have used these SDKs to create the consensus engines for the PoET engine (Python), PBFT engine (Rust), and Raft engine (Rust).

These SDKs have a consistent design with an abstract Engine class, an engine Driver, and a validator Service. The abstract Engine class provides a clear starting point for new consensus engine implementations. If you plan to write your own consensus SDK, we recommend conforming to this design.

Try it Today!

One of the most important decisions for a distributed ledger application is the choice of consensus. By opening up this interface, we hope that each application built on Hyperledger Sawtooth can select the consensus algorithm that suits it best.